Minutes, IBIS Quality Committee

28 Oct 2008

11-12 AM EST (8-9 AM PST)

ROLL CALL
  Adam Tambone
* Anders Ekholm, Ericsson
  Barry Katz, SiSoft
  Benny Lazer
  Benjamin P Silva
  Bob Cox, Micron
* Bob Ross, Teraspeed Consulting Group
  Brian Arsenault
  David Banas, Xilinx
* Eckhard Lenski, Nokia Siemens Networks
  Eric Brock
* Guan Tao, Huawei Technologies
  Gregory R Edlund
  Hazem Hegazy
  Huang Chunxing, Huawei Technologies
  John Figueroa
  John Angulo, Mentor Graphics
  Katja Koller, Nokia Siemens Networks
  Kevin Fisher
  Kim Helliwell, LSI Logic
  Lance Wang, IOMethodology
  Lynne Green
* Mike LaBonte, Cisco Systems
  Mike Mayer, SiSoft
  Moshiul Haque, Micron Technology
* Pavani Jella, TI
  Peter LaFlamme
  Randy Wolff, Micron Technology
  Radovan Vuletic, Qimonda
  Robert Haller, Enterasys
  Roy Leventhal, Leventhal Design & Communications
  Sherif Hammad, Mentor Graphics
  Todd Westerhoff, SiSoft
  Tom Dagostino, Teraspeed Consulting Group
  Kazuyoshi Shoji, Hitachi
  Sadahiro Nonoyama

Everyone in attendance marked by *

NOTE: "AR" = Action Required.

-----------------------MINUTES ---------------------------
Mike LaBonte conducted the meeting.

Call for patent disclosure:

- No one declared a patent.

AR Review:

- None

New items:

- Mike is unable to meet next week

Continued review of the IBIS Quality Specification:

5.5.3.	{LEVEL 2}  [Ramp] test fixture has no reactives
- This is a basic IBIS requirement
- We decided to delete this check

5.5.7.	{LEVEL 2}  [Ramp] dV consistent with V-T table endpoints
- Mike: Maybe we should remove the discussion of reactives at the end of this.
  - Bob: Agree
- Bob: The IBIS spec discourages *_dut parameters.
  - Wave R_fixture, V_fixture* ONLY are encouraged.
  - Mike: Wouldn't a quality IBIS model follow that advice?
- Bob: Some tools handle small reactives OK
  - Pre-emphasis models can use some C to compensate
  - Bob wrote a paper on this
  - Could have reactive fixturess in 3rd+ waveforms
    - Most tools tend to read only the first two waveforms
    - Some tools might be able to use the others
- Mike: Model makers should de-embed any reactive effects from waveforms
  - The C_* and L_* parameters would be omitted

5.5.4.	{LEVEL 2}  [Ramp] typ/min/max order is correct
- We decided to leave this as is

5.5.5.	{LEVEL 2}  [Ramp] data dv and dt values positive
- IBISCHK catches this
- This explains an s2ibis resolution problem
- Anders: The issue is poor resolution of waveforms to extract the data
  - Mike: This may be a process problem, not affecting just one model
    - The IQ specification need not address issues that might come up
      while developing a process, but not likely after that
  - Anders: Some vendors produce inconsistent quality
- Long ramp simulations would also give long waveforms too
  - Bob: s2ibis has only one parameter for simulation duration
- We decided to delete this check

5.5.6.	{LEVEL 2}  [Ramp] dV consistent with supply voltages
- Is this reasonable?
- Bob: [* Reference] are overrides to [Voltage Range]
- Bob: The buffer itself could ring, causing higher than expected peaks
  - But the capture would have to be too short to catch the overshoot
  - Only the first and last points of waveforms are used for this
  - R_load=50 already truncates the voltage swing
- Eckhard: One 3.3V model had dV = 2.5, for example
  - That is 76%, not 60%
- IBISCHK does not check this
- Mike: We should file a parser bug for this
- Bob: Anders brought up the idea of error code numbers for IBISCHK
- We decided to keep this

- Anders: Found a model with negative dV and [Voltage Range]
  - IBISCHK does not check for negative [Voltage Range]
  - Bob: [Voltage Range] can be negative, but Ramp dV will be a percentage of it
    - ECL can have [Voltage Range] = 0
    - It is a problem to propose a negative V test in IBISCHK

AR: Mike propose IBISCHK bug for 5.5.6

(returning to 5.5.7)
5.5.7.	{LEVEL 2}  [Ramp] dV consistent with V-T table endpoints
- Mike: this only works if Waveform fixtures happen to match Ramp fixtures
  - Anders: It should be possible to scale for R value
  - Mike: Can the IV tables be use to postulate what the Ramp dV should be?
- Bob: IBISCHK could check dV using only the I-V tables
  - Anders: So we would use IV tables to calculate Ramp dV
  - Mike: We could use this for 5.5.7, and use waveforms for 5.5.8
  - Bob: IBISCHK could do this
    - The code is already there for this, using a dummy waveform

- Several of us will be in China Nov 11
  - The next meeting will be Nov 18

Next meeting:

18 Nov 2008 11-12 AM EST (8-9 AM PST)

Meeting ended at 12:05 PM Eastern Time.